ASP.NET Applications and the Web Server

1. How Web Servers Work

The easiest job a web server has is to provide ordinary HTML pages. When you request such a file, the web server simply reads it off the hard drive (or retrieves it from an in-memory cache) and sends the complete document to the browser, which displays it. In this case, the web server is just a glorified file server that waits for network requests and dishes out the corresponding documents.

When you use a web server in conjunction with dynamic content such as an ASP.NET page, something more interesting takes place. On its own, the web server has no idea how to process ASP.NET tags or run VB code. However, it's able to enlist the help of the ASP.NET engine to perform all the heavy lifting. Figure 1 diagrams how this process works for ASP and ASP.NET pages. For example, when you request the page Default.aspx, the web server sends the request over to the ASP.NET engine (which starts automatically if needed). The ASP.NET engine loads the requested page, runs the code it contains, and then creates the final HTML document, which it passes back to IIS. IIS then sends the HTML document to the client.

Figure 1. How IIS handles a request

At this point, you might be wondering how the web server knows when it needs to get the ASP or ASP.NET engine involved. Essentially, the web server looks at the file extension of the requested page (such as .asp or .aspx) to determine the type of content. The web server compares this extension against a list to determine what program owns this file type. For example, the web server's list indicates that the .aspx extension is owned by the aspnet_isapi.dll component in a folder like c:\Windows\Microsoft.NET\Framework64\v4.0.30319 directory (assuming you're using version 4.0.3319 of .NET on a 64-bit system).

All web servers perform the same task as that shown in Figure 1. However, when you run an ASP.NET application in Visual Studio, you don't need to worry about deployment and file type registration. That's because Visual Studio includes a built-in web server. It receives the requests for the pages in your web application and then runs the corresponding code. This test web server has a significant limitation—it only accepts requests from the local computer. In other words, there's no way for other people on other computers to access your website.

To run your web application outside the development environment, you need a more powerful web server. The web server software runs continuously on your computer (or, more likely, a dedicated server). This means it's ready to handle HTTP requests at any time and provide your pages to clients who connect from the same network or over the Internet. On Microsoft Windows operating systems, the web server you'll use is IIS.

In most cases, you won't be developing on the same computer you use to host your website. If you do, you will hamper the performance of your web server by tying it up with development work. You will also frustrate clients if a buggy test application crashes the computer and leaves the website unavailable or if you accidentally overwrite the deployed web application with a work in progress. Generally, you'll perfect your web application on another computer and then copy all the files to the web server.

2. The Virtual Directory

When you deploy your web application to a web server, it's exposed through something called a virtual directory. A virtual directory is simply the public face of your website directory.

For example, your website might exist in a directory on the server named c:\MySite. To allow remote users to access this website through their browsers, you could expose it as a virtual directory. The virtual directory name might match the real directory name (in this case, MySite), or it might be something different. When the user requests a page in a virtual directory (say, http://WebServer/MySite/Checkout.aspx), the web server looks for the corresponding file in the corresponding physical directory (c:\MySite\Checkout.aspx). You'll learn more about this process—how URL requests are processed by the web server—in the next section.

3. Web Application URLs

You can use ASP.NET applications in a variety of different environments, including local area networks (LANs) and over the Internet. To understand the difference, it helps to review a little about how web servers work with networks and the Internet.

A network is defined simply as a group of devices connected by communication links. A traditional LAN connects devices over a limited area, such as within a company site or an individual's house. Multiple LANs are connected into a wide area network (WAN) using a variety of technologies. In fact, the Internet is nothing more than a high-speed backbone that joins millions of LANs.

The cornerstone of the Internet is Internet Protocol (IP). On an IP network, each computer is given a unique number called an IP address. An IP address is typically written as four numbers from 0 to 255 separated by periods (as in 192.145.0.1) or as six hexadecimal values separated by colons (as in 2001:db8:85a3::8a2e:370:7334). The difference depends on the version of the IP standard that you're using—the older, more common IPv4 standard uses the first approach, while the newer IPv6 uses the second. Either way, to access another computer over a network, you need to use its IP address.

Of course, IP addresses aren't easy to remember and don't make for great marketing campaigns. To make life easier, web servers on the Internet usually register unique domain names such as www.microsoft.com. This domain name is mapped to the IP address by a special catalog, which is maintained by a network of servers on the Internet. This network, called the Domain Name Service (DNS), is a core part of the infrastructure of the Internet. When you type http://www.microsoft.com in a web browser, the browser contacts a DNS server, looks up the IP address that's mapped to www.microsoft.com, and contacts it.

So, what effect does all this have on the accessibility of your website? To be easily reached over the Internet, the web server you use needs to be in the DNS registry. To get in the DNS registry, you must have a fixed IP address. Commercial Internet service providers won't give you a fixed IP address unless you're willing to pay a sizable fee. In fact, most will place you behind a firewall or some type of network address translation (NAT), which will hide your computer's IP address. The same is true in most company networks, which are shielded from the outside world.

ASP.NET applications don't need to be accessible over the Internet. Many are useful within an internal network. In this case, you don't need to worry about registered domain names. Other computers can access your website using either the IP address of your machine or, more likely, the network computer name.

For example, imagine you deploy an application to a virtual directory named MyWebApp. On the web server, you can access it like this:

http://localhost/MyWebApp

Assuming the computer is named MyWebServer, here's how you can access the virtual web directory on another computer on the same LAN:

http://MyWebServer/MyWebApp

Now, assume that MyWebServer is registered in the DNS as www.MyDomain.com and is exposed to the Internet. You could then use the following URL:

http://www.MyDomain.com/MyWebApp

Finally, you can always use the computer's IP address, provided the computer is on the same network or visible on the Internet. Assuming the IP address is 123.5.123.4, here's the URL you would use:

http://123.5.123.4/MyWebApp

Because internal networks often use dynamic IP addresses and because DNS registration changes, using the computer name or domain name to access a website is almost always the best approach.

If you study the URLs that the built-in web server in Visual Studio uses, you'll notice they're a little different than what you usually see when surfing the Internet. Namely, they include a port number. That means instead of requesting a page like this:

http://localhost/MyWebApp/Default.aspx

you might request a page like this:

http://localhost:2040/MyWebApp/Default.aspx

That's because the Visual Studio web server watches requests on a dynamically chosen port number. (In this example, the port number is 2040, but you'll see that it changes each time you run Visual Studio.) By using a dynamic port number, Visual Studio makes sure its built-in web server doesn't infringe on any other web server software you have on the computer.

Real web servers are almost always configured to monitor port 80 (and port 443 for encrypted traffic). If you don't type in a port number for a URL, the browser assumes you're using port 80 for ordinary web access and port 443 for secure connections.

4. Web Farms

Some applications run on web farms, a group of server computers that share the responsibility of handling requests. Usually web farms are reserved for high-powered web applications that need to be able to handle heavy loads, because multiple computers can deal with more simultaneous surfers than a single web server. However, web farms are overkill for many small and midsized websites.

The way a web farm works is deceptively simple. Essentially, instead of placing web application files on a single web server, you place a copy on several separate web servers. When a request is received for your website, it's directed to one of these web servers (based on which one has the lightest load). That web server then deals with the request. Obviously, if you decide to update your application, you need to make sure you update each web server in the web farm with the same version to prevent discrepancies.

Some web hosting companies use web farms to host multiple websites. For example, your website might be running on more than one web server, but each of these web servers might also host multiple websites. This provides a flexible deployment model that lets different web applications share resources. However, web farms also introduce a few new challenges. If you're setting up a web farm of your own, you'll need to make sure each computer uses the same machine key.